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Abstract 


The setup of a full mesh of Multi-Protocol Label Switching (MPLS) 
Traffic Engineering (TE) Label Switched Paths (LSP) among a set of 
Label Switch Routers (LSR) is a common deployment scenario of MPLS 
Traffic Engineering either for bandwidth optimization, bandwidth 
guarantees or fast rerouting with MPLS Fast Reroute. Such deployment 
may require the configuration of a potentially large number of TE 
LSPs (on the order of the square of the number of LSRs). This 
document specifies Interior Gateway Protocol (IGP) routing extensions 
for Intermediate System-to-Intermediate System (IS-IS) and Open 
Shortest Path First (OSPF) so as to provide an automatic discovery of 
the set of LSRs members of a mesh in order to automate the creation 
of such mesh of TE LSPs. 
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1. Introduction 


There are two well-known approaches in deploying MPLS Traffic 
Engineering: 


(1) The so-called "strategic" approach that consists of setting up a 
full mesh of TE LSPs between a set of LSRs. 


(2) The so-called "tactical" approach, where a set of TE LSPs are 
provisioned on well-identified "hot spots" in order to alleviate a 
congestion resulting, for instance, from an unexpected traffic growth 
in some parts of the network. 


The setup of a full mesh of TE LSPs among a set of LSRs is a common 
deployment scenario of MPLS Traffic Engineering either for bandwidth 
optimization, bandwidth guarantees, or fast rerouting with MPLS Fast 
Reroute. Setting up a full mesh of TE LSPs between N LSRs requires 
the configuration of a potentially large number of TE LSPs (O(N^2)). 
Furthermore, the addition of any new LSR in the mesh requires the 
configuration of N additional TE LSPs on the new LSR and one new TE 
LSP on every LSR of the existing mesh destined to this new LSR, which 
gives a total of 2*N TE LSPs to be configured. Such an operation is 
not only time consuming but also risky (prone to misconfiguration) 
for Service Providers. Hence, an automatic mechanism for setting up 
TE LSPs meshes is desirable and requires the ability to automatically 
discover the set of LSRs that belong to the mesh. This document 
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specifies routing extensions so as to automatically discover the 
members of a mesh, also referred to as a "TE mesh-group". Note that 
the mechanism(s) needed for the dynamic creation of TE LSPs is 
implementation specific and outside the scope of this document. 


Routing extensions have been defined in [RFC4970] and [RFC4971] in 
order to advertise router capabilities. This document specifies IGP 
(OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs allowing for 
the automatic discovery of a TE mesh-group members, to be carried in 
the OSPF Router Information (Link State Advertisement) LSA [RFC4970] 
and IS-IS Router Capability TLV [RFC4971]. The routing extensions 
specified in this document provide the ability to signal multiple TE 
mesh groups. An LSR may belong to more than one TE mesh-group(s). 
There are relatively tight real-time constraints on the operation of 
IGPs (such as OSPF and IS-IS). For this reason, some care needs to 
be applied when proposing to carry additional information in an IGP. 
The information described in this document is both relatively small 
in total volume (compared with other information already carried in 
IGPs), and also relatively stable (i.e., changes are based on 
configuration changes, but not on dynamic events within the network, 
or on dynamic triggers, such as the leaking of information from other 
routing protocols or routing protocol instances). 

2. Definitions 
Terminology used in this document 
IGP: Interior Gateway Protocol 
IGP Area: OSPF area or IS-IS level 
IS-IS: Intermediate System-to-Intermediate System (IS-IS) 
LSR: Label Switch Router 
OSPF: Open Shortest Path First 
OSPF LSA: OSPF Link State Advertisement 
TE LSP: Traffic Engineering Label Switched Path 
TE LSP head-end: head/source of the TE LSP 
TE LSP tail-end: tail/destination of the TE LSP. 


TLV: Type Length Value 
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2.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. Description of a TE Mesh-Group 


A TE mesh-group is defined as a group of LSRs that are connected by a 
full mesh of TE LSPs. Routing extensions are specified in this 
document, allowing for dynamic discovery of the TE mesh-group 
members. Procedures are also specified for a member to join and 
leave a TE mesh-group. For each TE mesh-group membership announced 
by an LSR, the following information is advertised: 


- A mesh-group number identifying the TE mesh-group that the LSR 
belongs to, 


- A tail-end address (used as the TE LSP Tail-end address by other 
LSRs belonging to the same mesh-group), 


- A tail-end name: a display string that is allocated to the tail- 
end used to ease the TE-LSP naming. 


4. TE-MESH-GROUP TLV Formats 

4.1. OSPF TE-MESH-GROUP TLV Format 
The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to 
join/leave a given TE mesh-group. No sub-TLV is currently defined 


for the TE-MESH-GROUP TLV. 


The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information 
LSA defined in [RFC4970]) has the following format: 
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Figure 1 - OSPF TE-MESH-GROUP TLV format 
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Type: 
Length: 
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identifies the TLV type 
the length of the value field in octets 


July 2007 


The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 
format used by the Traffic Engineering Extensions to OSPF 


(see [RFC3630]). 


have a length of three, 


octets). 
are ignored. 
vendor-specific extensions. 


The TLV is padded to a four-octet alignment; 
is not included in the length field 


padding 


(so a three-octet value would 


but the total size of the TLV would be eight 
Unrecognized types 


Nested TLVs are also 32-bit aligned. 
All types between 32768 and 65535 are reserved for 
All other undefined type codes are 


reserved for future assignment by IANA. 


The OSPF TE-MESH-GROUP TLV format for IPv4 


(Figure 3) is as follows: 
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Figure 3 - OSPF TE-MESH-GROUP TLV format 


w 


+ 


+ 


-+ 


-+ 


-+ 


-+ 


-+ 


Oo 


+ 


+ 


-+-+-+- 


œ 


+ 


+ 


July 


Ke) 


+ 


+ 


+— 


+— 


+— 


+— 


+— 


+— 


(IPv6 Address) 


The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group 


entries, 


of the following fields: 


- A mesh-group-number that identifies the mesh-group number. 


- A Tail-end address: 


- Name length field: An integer, 


an IPv4 or IPv6 IP address to be used as a 
tail-end TE LSP address by other LSRs belonging to the same mesh- 
group. 


the length of the Tail-end name before padding. 


expressed in octets, 


2007 
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that indicates 


- A Tail-end name: A display string that is allocated to the Tail- 


end. 


facilitate the TE LSP identification. 
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4.2. IS-IS TE-MESH-GROUP Sub-TLV Format 


The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR 
to join/leave a given TE mesh-group. No sub-TLV is currently defined 
for the TE-MESH-GROUP sub-TLV. 


The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY 
TLV defined in [RFC4971]) is composed of 1 octet for the type, 1 
octet specifying the TLV length and a value field. The format of the 
TE-MESH-GROUP sub-TLV is identical to the TLV format used by the 
Traffic Engineering Extensions for IS-IS [RFC3784]. 


The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (Figure 4) and IPv6 
(Figure 5) is as follows: 


TYPE: 3 
LENGTH: Variable 
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mesh-group-number 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tail-end IPv4 address 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Name length | Tail-end name 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
// // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| mesh-group-number n | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Tail-end IPv4 address n 
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| Name length | Tail-end name n 
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Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address) 
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The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group 
entries where each entry correspond to a TE mesh-group and is made 
the following fields: 


- A mesh-group-number that identifies the mesh-group number. 


- A Tail-end address: 
tail-end TE LSP address by other LSRs belonging to the same mesh- 
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- Name length field: An integer, 


up. 


an IPv4 or IPv6 IP address to be used as a 
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5. Elements of Procedure 


The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing 
Information LSA and the IS-IS TE-MESH-GROUP sub-TLV is carried within 
the IS-IS Router capability TLV. As such, elements of procedure are 
inherited from those defined in [RFC4970] and [RFC4971] for OSPF and 
IS-IS respectively. Specifically, a router MUST originate a new 
LSA/LSP whenever the content of this information changes, or whenever 
required by regular routing procedure (e.g., updates). 


The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one 
of each of the IPv4 instances or the IPv6 instance. If either the 
IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within 
the OSPF Router Information LSA, only the first instance is 
processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, 
if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs 
more than once within the IS-IS Router capability TLV, only the first 
instance is processed, subsequent TLV(s) SHOULD be silently ignored. 


5-1 OSBE 


The TE-MESH-GROUP TLV is advertised within an OSPF Router Information 
opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328] 
and within a new LSA (Router Information LSA) for OSPFv3 [RFC2740]. 
The Router Information LSAs for OSPFv2 and OSPFv3 are defined in 
[RFC4970]. 


A router MUST originate a new OSPF router information LSA whenever 
the content of any of the advertised TLV changes or whenever required 
by the regular OSPF procedure (LSA update (every LSRefreshTime)). If 
an LSR desires to join or leave a particular TE mesh group, it MUST 
originate a new OSPF Router Information LSA comprising the updated 
TE-MESH-GROUP TLV. In the case of a join, a new entry will be added 
to the TE-MESH-GROUP TLV; conversely, if the LSR leaves, a mesh-group 
the corresponding entry will be removed from the TE-MESH-GROUP TLV. 
Note that both operations can be performed in the context of a single 
LSA update. An implementation SHOULD be able to detect any change to 
a previously received TE-MESH-GROUP TLV from a specific LSR. 


As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the 
flooding scope of the Router Information LSA is determined by the LSA 
Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. 
For OSPFv2 Router Information opaque LSA: 


- Link-local scope: type 9; 


- Area-local scope: type 10; 
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- Routing-domain scope: type 11. In this case, the flooding scope 
is equivalent to the Type 5 LSA flooding scope. 


For OSPFv3 Router Information LSA: 


- Link-local scope: OSPFv3 Router Information LSA with the S1 and S2 
bits cleared; 


- Area-local scope: OSPFv3 Router Information LSA with the S1 bit 
set and the S2 bit cleared; 


- Routing-domain scope: OSPFv3 Router Information LSA with S1 bit 
cleared and the S2 bit set. 


A router may generate multiple OSPF Router Information LSAs with 
different flooding scopes. 


The TE-MESH-GROUP TLV may be advertised within an Area-local or 
Routing-domain scope Router Information LSA, depending on the MPLS TE 
mesh group profile: 


- If the MPLS TE mesh-group is contained within a single area (all 
the LSRs of the mesh-group are contained within a single area), 
the TE-MESH-GROUP TLV MUST be generated within an Area-local 
Router Information LSA. 


- If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- 
group TLV MUST be generated within a Routing-domain scope router 
information LSA. 


S2. JTS=1S 


The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 
CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST originate 
a new IS-IS LSP whenever the content of any of the advertised sub-TLV 
changes or whenever required by regular IS-IS procedure (LSP 
updates). If an LSR desires to join or leave a particular TE mesh 
group, it MUST originate a new LSP comprising the refreshed IS-IS 
Router capability TLV comprising the updated TE-MESH-GROUP sub-TLV. 
In the case of a join, a new entry will be added to the TE-MESH-GROUP 
sub-TLV; conversely, if the LSR leaves a mesh-group, the 
corresponding entry will be deleted from the TE-MESH-GROUP sub-TLV. 
Note that both operations can be performed in the context of a single 
update. An implementation SHOULD be able to detect any change to a 
previously received TE-MESH-GROUP sub-TLV from a specific LSR. 


If the flooding scope of a TE-MESH-GROUP sub-TLV is limited to an 
IS-IS level/area, the sub-TLV MUST not be leaked across level/area 
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and the S flag of the Router CAPABILITY TLV MUST be cleared. 
Conversely, if the flooding scope of a TE-MESH-GROUP sub-TLV is the 
entire routing domain, the TLV MUST be leaked across IS-IS 
levels/areas, and the S flag of the Router CAPABILITY TLV MUST be 
set. In both cases, the flooding rules specified in [RFC4971] apply. 


As specified in [RFC4971], a router may generate multiple IS-IS 
Router CAPABILITY TLVs within an IS-IS LSP with different flooding 
scopes. 


6. Backward Compatibility 


The TE-MESH-GROUP TLVs defined in this document do not introduce any 
interoperability issue. For OSPF, a router not supporting the TE- 
MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 
[RFC2370]. For an IS-IS, a router not supporting the TE-MESH-GROUP 
sub-TLV SHOULD just silently ignore the sub-TLV. 


7. IANA Considerations 
7.1. OSPF 
The registry for the Router Information LSA is defined in [RFC4970]. 


IANA assigned a new OSPF TLV code-point for the TE-MESH-GROUP TLVs 
carried within the Router Information LSA. 


Value Sub-TLV References 
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc) 
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc) 


Taze. -TS=ES 


The registry for the Router Capability TLV is defined in [RFC4971]. 
IANA assigned a new IS-IS sub-TLV code-point for the TE-MESH-GROUP 
sub-TLVs carried within the IS-IS Router Capability TLV. 


Value Sub-TLV References 
3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc) 
4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc) 
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8. 


10. 


10. 


Security Considerations 


The function described in this document does not create any new 
security issues for the OSPF and IS-IS protocols. Security 
considerations are covered in [RFC2328] and [RFC2740] for the base 
OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the 
advertisement of "fake" TE Mesh Group membership(s) by a mis- 
configured or malicious LSR Y would not have any major impact on the 
network (other than overloading the IGP), such as triggering the set 
up of new MPLS TE LSP: indeed, for a new TE LSP originated by another 
LSR X destined to LSR Y to be set up, the same TE Mesh group 
membership must be configured on both LSRs. Thus such fake 
advertisement could not amplify any Denial of Service (DoS) attack. 
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